This lesson is part of the Alarming in Ignition course. You can browse the rest of the lessons below.

LESSON LIST

Autoplay Off

Description

The Alarm Journal Table provides a built-in view to explore alarm history that has been stored in an Alarm Journal.

Video recorded using: Ignition 8.1

Transcript

(open in window)

[00:00] In this video, we are going to take a look at the alarm journal table component. The alarm journal table is designed to show alarm events that have already been stored in the database by the alarm journal system. Now, while the alarm events stored in the database can be manually queried out using a SQL query, the alarm journal table makes it easy and offers some additional built-in functionality. If we drag an alarm journal table onto the screen, we can see that it actually bears a lot of similar functionality to the alarm status table. The biggest difference between the two is that while the alarm status table shows current live events, the alarm journal table shows events that have already happened in the past and have been stored to the database. Now just like the alarm status table, we can put our designer into preview mode and sort the events by clicking on specific headers, rearrange the columns by clicking and dragging them around, or add and remove columns by right clicking on the header and making new selections.

[01:10] We also have some buttons on the bottom that allow us to focus on a specific alarm event or see more details about an event. At the bottom of the list of properties, we have some of the different properties that can filter the alarm events being displayed. We can filter on the type of event, the event's priority, or even matching a string to a specific part of the alarm. One of the really neat things about these filters is that some of them are built into the filter button that is available to the user, allowing the user to select how they want to filter events. The last thing I want to go over is how the component updates. Because this component is pulling data from the database, it is not always pulling for new data. The data that gets displayed is based on a range of time, which is specified in the start and end date properties here.

[02:03] By default, the properties both start with no date, which will pull in the last eight hours of events. The component will re-query the database anytime the start or end date properties change. This is typically done using a date range component, which has a start date and an end date property, and allows the user to pick a range of times. We simply need to bind the start and end date of the alarm journal to the start and end date of the date range. Once we have those bindings set up, moving the slider allows us to change the timeframe of events that the alarm journal table is showing, pulling in all events during that timeframe. it is also possible to have a date that is constantly updating by using an expression binding with the date time functions, such as now on the start and end date of the alarm journal component.

You are editing this transcript.

Make any corrections to improve this transcript. We'll review any changes before posting them.